經過 30 天的連載，我們從「一個沒有防禦的 n8n + MCP 工作流」出發，一步步建立起完整的 AI 工具鏈防禦體系。這不只是技術實作的記錄，更是一場關於「信任、授權與可控性」的思考實驗。

從零開始的威脅模型

系列初期（Day 1–5）聚焦在理解威脅與建立最小原型。
我們首先釐清了 MCP（Model Context Protocol）與 n8n 的關聯：前者負責讓 AI 能安全呼叫外部工具，後者則負責自動化工作流。
然而，一旦接口外露、驗證缺失或工具權限過大，這兩者就可能被駭客利用成為攻擊跳板。
因此，我們從模擬 webhook 任意呼叫開始，建立第一道防線：API Key 驗證。

藍隊防線的層層構築

中期（Day 6–15）是整個系列的防禦核心。我們將安全機制分層落實：

• #2 輸入驗證：限制 payload 格式，避免惡意指令與注入。
• #3 最小權限設計：MCP 僅能呼叫白名單工具。
• #4 白名單目標：n8n 僅允許掃描內網 IP。
• #5 API Key 防重放：timestamp + nonce 結合 HMAC，有效抵禦重放攻擊。
• #6 限流與日誌監控：透過 n8n execution log 與 k6 測試驗證可用性。
• #7 Credential 安全儲存：避免憑證明文出現在 workflow 或 plugin 內。
• #9 Plugin 白名單與簽章驗證：防止惡意模組混入 CI/CD 或 Marketplace。

這些策略不僅對應不同的威脅場景，也逐步形塑出「預設封鎖、逐步授權」的安全文化。

紅隊攻擊與藍隊反制

從中後段（Day 16–25）開始，我們反過來扮演攻擊者，透過多個真實模擬案例：

• 惡意 payload 利用 n8n 工具進行 Port Scan
• API Key 遭竊取後的重放測試
• plugin 混入供應鏈污染
• 駭客透過 MCP 指令誤用內部工具

每一次紅隊測試都伴隨著防禦策略優化。例如在模擬攻擊後，我們改良 workflow 的驗證邏輯、限制工具範圍、加入異常監控與封鎖機制，並在 n8n + MCP 之間實現自動化 playbook。

自動化防禦與演練文化

最後幾天（Day 26–30），我們以 攻防演練與流程銜接 作收尾。
透過 n8n + SOAR 思維，我們定義了一條完整事件流程：
攻擊觸發 → 偵測 → 自動化反制 → 人工確認 → RCA 回饋 → 改善。
這不只是技術練習，而是一種 DevSecOps 文化的落地實踐。
我們學到：防禦不是一次設定完畢，而是需要不斷演練、調整、量化指標（MTTR、誤封率、偵測延遲）來進化。

結語：安全是信任的基礎

MCP × n8n 的整合讓 AI 工具更強大，但也更容易被濫用。
唯有建立完整的防禦鏈條—from Key 驗證、權限控管、白名單設計到自動化回應—才能確保 AI 系統在效率與安全之間取得平衡。

這 30 天的實戰讓我深刻體會一句話：

「安全不是功能，而是品質的一部分。」

希望這套實作能成為所有開發者在導入 AI 自動化時的一面鏡子，也打造可信賴的 AI 執行環境提供藍圖。